En una Descomposición Orientada a Flujos de Funciones o Modelo de Flujo de Datos, las transformaciones funcionales procesan sus entradas y producen salidas.
Los datos fluyen de una función a otra y se transforman a medida que se mueven a través de la secuencia de funciones.
Cada paso de procesamiento se implementa como una transformación.
Los datos de entrada fluyen a través de estas transformaciones hasta que se convierten en datos de salida.
Descomposición orientada a Flujos de Funciones
Las transformaciones se pueden ejecutar secuencialmente o en paralelo.
Los datos pueden ser procesados por cada transformación elemento a elemento o en un único lote.
Cuando las transformaciones son secuenciales con datos procesados por lotes, este modelo arquitectónico es un modelo secuencial por lotes.
Es una arquitectura común para sistemas de procesamiento de datos tales como sistemas de facturación.
Descomposición orientada a Flujos de Funciones
Los Sistemas de Procesamiento de Datos suelen generar muchos informes de salida, que se derivan, a partir de cálculos simples, sobre un gran número de registros de entrada.
El Modelo de Objetos es más abstracto en tanto que no incluye información sobre la secuencia de operaciones.
Descomposición orientada a Flujos de Funciones
Modelo de Flujo de Funciones (sistema de procesamiento de facturas):
Descomposición orientada a Flujos de Funciones
Ventajas de esta Arquitectura:
1. Permite la reutilización de transformaciones.
2. Es intuitiva y lógica (muchas personas piensan su trabajo en términos de procesamiento de entradas y salidas).
3. Se puede evolucionar, en forma directa, al sistema, añadiéndole nuevas transformaciones.
4. Es sencilla de implementar (como sistema concurrente o secuencial).
Descomposición orientada a Flujos de Funciones
Desventajas:
Tiene que haber un formato común para transferir los datos, para que puedan ser reconocidos por todas las transformaciones.
Cada transformación debe estar acorde con las transformaciones con las que se comunica, o bien se debe imponer un formato estándar para todos los datos comunicados.
Esto incrementa la sobrecarga del sistema y puede hacer imposible integrar transformaciones que utilicen formatos incompatibles de datos.
Descomposición orientada a Flujos de Funciones
Los sistemas interactivos son difíciles de describir usando el modelo de flujo de funciones.
Mientras que un modelo textual sencillo de entradas y salidas puede modelarse de esta forma, las interfaces gráficas de usuario tienen fórmalos de entrada/salida más complejos y controles (que se basan en eventos, tales como pulsaciones del ratón o selecciones de menús).
Es difícil traducir esto a un modelo de flujo de funciones.
Descomposición orientada a Flujos de Funciones
Los modelos para estructurar un sistema están relacionados con la forma en que un sistema se descompone en subsistemas.
Para trabajar como un sistema, los subsistemas deben ser controlados para que sus servicios se entreguen en el lugar correcto, en el momento preciso.
El diseñador debe organizar los subsistemas, de acuerdo con algún modelo de control que complemente el modelo de estructura usado.
Los modelos de control a nivel arquitectónico están relacionados con el flujo de control entre subsistemas.
Estilos de Control
Hay dos estilos de control genéricos:
1. Control centralizado. Un subsistema tiene toda la responsabilidad para controlar, iniciar y detener a otros subsistemas.
También puede devolver el control a otro subsistema, pero esperará que le sea devuelta la responsabilidad del control.
2. Control basado en eventos. En vez de que la información de control esté embebida en un subsistema, cada subsistema puede responder a eventos generados externamente.
Estos eventos podrían provenir de otros subsistemas o del entorno del sistema.
Estilos de Control
Un subsistema se diseña como el controlador del sistema y tiene la responsabilidad de gestionar la ejecución de otros subsistemas.
Los modelos de control centralizado se dividen en dos clases, según que los subsistemas controlados se ejecuten secuencialmente o en paralelo.
Control Centralizado
1. Modelo de llamada-retorno. Es el modelo de subrutina descendente, en donde el control comienza al inicio de una jerarquía de subrutinas y, a través de las llamadas a subrutinas, el control pasa a niveles inferiores en el árbol de la jerarquía.
Este modelo solo es aplicable a sistemas secuenciales.
Control Centralizado
Ejemplo del modelo de llamada-retorno
2. El modelo del gestor. Es aplicable a sistemas concurrentes.
Un componente del sistema se diseña como un gestor del sistema y controla el inicio, parada y coordinación del resto de los procesos del sistema.
Un proceso es un subsistema o módulo que puede ejecutarse en paralelo con otros procesos.
El Modelo del Gestor
La naturaleza rígida y restrictiva de este modelo es tanto una ventaja como un inconveniente.
Es una ventaja debido a que es relativamente simple analizar flujos de control y conocer cómo responderá el sistema a cierto tipo de entradas.
Es un inconveniente debido a que las excepciones a las operaciones normales son difíciles de manejar.
Este modelo se usa en sistemas de tiempo real «blandos», los cuales no tienen restricciones de tiempo muy estrictas.
Control Centralizado
El controlador central gestiona la ejecución de un conjunto de procesos asociados.
El proceso controlador del sistema decide cuándo deberían comenzar o terminar los procesos, dependiendo de las variables de estado del sistema.
El sistema comprueba si otros procesos han producido información para ser procesada o para enviarles información para su procesamiento.
El controlador por lo general realiza ciclos continuamente, consultando los sensores y otros procesos para detectar eventos o cambios de estado.
Por esta razón, este modelo se llama también modelo de ciclo de eventos.
El Modelo del Gestor
Ejemplo de modelo de gestión de control centralizado para un sistema concurrente (en tiempo real):
El Modelo del Gestor
En los modelos de control centralizados, las decisiones de control se determinan por los valores de algunas variables de estado del sistema.
En cambio, los modelos de control dirigidos por eventos se rigen por eventos generados externamente.
Evento puede ser una señal binaria, otra señal dentro de un rango de valores o la entrada de un comando desde un menú.
Sistemas Dirigidos por Eventos
Hay muchos tipos de sistemas dirigidos por eventos.
Por ejemplo: editores => donde los eventos de la interfaz de usuario provocan la ejecución de comandos.
Hay dos modelos de control dirigidos por eventos:
1. Modelos de transmisión (broadcast). Acá, un evento se transmite a todos los subsistemas. Cualquier subsistema que haya sido programado para manejar ese evento le puede responder.
2. Modelos dirigidos por interrupciones. Se usan en sistemas de tiempo real, donde las interrupciones externas son detectadas por un manejador de interrupciones. Luego, éstas se envían a algún otro componente para su procesamiento.
Sistemas Dirigidos por Eventos
 Página anterior | Volver al principio del trabajo | Página siguiente  |